Hallo bei allen. Einige kennen mich schon aus den Übungen, für die anderen. Mein Name ist Frank Lauterwald, ich bin Assistent am Lehrstuhl für Datenmanagement und Professor Lenz ist heute leider krank, deswegen habe ich das Vergnügen, ihn zu vertreten.

Ja, um was soll es heute gehen? Thema ist multidimensionale Modellierung. Ganz grob, wie kommen wir dazu? Über was werden wir uns unterhalten?

Im Prinzip ist es so, dass wir spezielle Anforderungen haben an unsere Datenmodellierung für bestimmte Anwendungsfälle.

Der Anwendungsfall, der uns hier interessiert, ist Datenanalyse. Man hat festgestellt, was wir bisher so gelernt haben an Datenmodellen, war zur Datenanalyse nicht so furchtbar gut geeignet, also schauen wir uns da heute eine andere Variante an, die darauf Maß geschneidert ist.

Diese Variante wird multidimensionales Datenmodell genannt, das ist also der zweite Punkt auf der Folie. Was ist überhaupt ein multidimensionales Datenmodell, wie sieht das aus, was kann man damit tun? Und speziell gibt es da zwei Konzepte, die sich Dimensionen und Fakten nennen, die werden wir uns genauer anschauen.

Dann werden wir die Frage beantworten, was ist ein Data Warehouse? Die Kurzform ist, ein Data Warehouse ist ein großes System zur Auswertung von Daten, genauer schauen wir es auch gleich noch an.

Und zu guter Letzt soll es darum gehen, dieses multidimensionale Datenmodell, das wir heute kennenlernen werden, das werden wir versuchen auf normale Relationen, wie wir sie schon kennen, abzubilden, sodass wir also normale, relationale Datenbanken verwenden können, um trotzdem mit diesen multidimensionalen Daten zu arbeiten.

Literaturempfehlung, das Buch Data Warehouse Systeme von Bauer und Günzel, der Andreas Bauer hat auch bei uns am Lehrstuhl mal gearbeitet, hat seine Doktorarbeit geschrieben, war leider vor meiner Zeit.

Ist aber ein hervorragendes Buch, die Vorlesung hält sich da relativ eng dran, obwohl wir natürlich unglaublich komprimieren. Also im Prinzip vom Aufbau ist das ganze Buch sehr ähnlich, es ist eben viel, viel ausführlicher.

Also, wie kommen wir zu unseren Problemen bei der Datenanalyse, um die es vor allem heute gehen soll? Wir schauen uns an, betriebliche Informationssysteme, also irgendwie Datenbankanwendungen, wie sie in Unternehmen eingesetzt werden.

Wie sieht das aus? Wir haben oben auf der Folie den Blog Produktionsumgebung, da sitzen, kann man sagen, unsere Anwender an Terminals und versuchen, irgendwas zu tun.

Dieses irgendwas kann jetzt sein auf der linken Seite, das sogenannte Online Transaction Processing, OLTP, das ist das, was wir bisher so kennen, das ist, arbeiten mit einzelnen Tupeln,

Daten einfügen, Daten anschauen, Daten ändern, macht man üblicherweise über vordefinierte Formulare, das heißt, es wird eine Anwendung geschrieben, die Anwendung zeigt den Leuten genau das, was sie sehen wollen und dann können sie eben Kunden und Rechnungen und Lieferungen damit verwalten.

Auf der rechten Seite haben wir den großen Bereich Online Analytical Processing, da soll es jetzt um die Auswertung gehen und die findet statt in einer sogenannten Data Warehouse Umgebung, das werden wir, wie gesagt, gleich noch etwas detaillierter sehen.

Und unten drunter haben wir diese große Blase, wo verschiedene Themen miteinander in Beziehung gesetzt werden. In der Mitte haben wir da das Data Warehousing selbst und da hängen jetzt so einzelne kleine Bläschen dran,

OLAP, also Online Analytical Processing, die Auswertung von Daten und zwar die relativ individuelle Auswertung von Daten.

Also potenziell sitzt da auch jemand an einem Rechner und sagt, ich hätte jetzt gerne diese und jene Daten in folgendem Format, weil ich eine Entscheidung treffen muss.

Weiter unten an diesem Kreis dran haben wir den Bereich Reporting, da geht es eher um vordefinierte Auswertungen, Monatsberichte, solche Sachen, was man auch einmal definieren kann und das wird dann halt einmal im Monat gerechnet und am Ende kann man sich das Ergebnis angucken.

Das ist also weniger individuell als das Online Analytical Processing und links unten am Data Warehousing haben wir noch dranhängendes Data Mining, darunter versteht man die Suche nach Zusammenhängen zwischen den Daten.

Also wir schauen uns unsere Daten an und versuchen da irgendwelche neuen Informationen drin zu finden, an die wir bisher noch überhaupt nicht gedacht haben.

Der weitere Kreis, in dem das alles eingefasst ist, ist beschrieben mit Business Intelligence, das ist im weitesten Sinne jede Art von Anwendung, die das Management unterstützen soll, Management-Entscheidungen zu treffen.

Wir haben da dran hängen auf der linken Seite Enterprise Resource Planning, also die Frage, wie setzen wir unsere Ressourcen ein, was lassen wir unsere Mitarbeiter tun, haben wir genug oder sollten wir welche einstellen?

Haben wir genug Gebäude, werden wir in Zukunft genug Gebäude haben, wenn wir jetzt neue Mitarbeiter einstellen und so weiter und so fort?

Da will man natürlich nicht in die Falle tappen und feststellen, jetzt geht es nicht mehr, sondern man will vorausplanen können.

Unten haben wir den Bereich Customer Relationship Management, also wie verwalte ich die Beziehungen zu meinen Kunden, wer macht vielleicht den Eindruck etwas unzufrieden zu sein in letzter Zeit, wem sollte ich mal Rabatte anbieten?

Wer sind meine besten Kunden, wen muss ich bevorzugt behandeln? Das kann ich natürlich auch gut aus den ganzen Daten, die in einem Unternehmen vorliegen, versuchen rauszulesen.

Und auf der rechten Seite haben wir Supply Chain Management, also die Frage, was sollten wir einkaufen, wie viel sollten wir kaufen, wann sollten wir es kaufen, sodass die Sachen alle da sind, wenn wir sie brauchen.

Das ist besonders interessant natürlich im produzierenden Gewerbe, ich tue mich schwer ein Auto zu bauen, wenn ich vergessen habe genug Amaturenbretter zu bestellen.

Gut, was uns heute vor allem beschäftigen wird, ist eben dieser Bereich Data Warehousing hier und da fokussiert Online Analytical Processing, also individuelle Auswertungen auf diesen großen Datenbeständen, die wir sowieso herumliegen haben im Unternehmen.

Jetzt habe ich gesagt, wir werden ein neues Datenmodell einführen, weil das, was wir bisher kennen, nicht so richtig geeignet ist für Auswertungen.

Und hier sind jetzt zwei gegenübergestellt, was wir primär bisher gehabt haben als Datenmodell war das Relationale, das war sehr einfach, wir haben im Prinzip nur Relationen, Attribute, mit Attributen kann man dann auch ein paar interessante Sachen machen, Primärschlüssel, Fremdschlüssel und so weiter.

Aber im Prinzip gibt es nur ganz wenige einfache Konzepte und mit denen kann man trotzdem alles machen, also das ist vollkommen anwendungsneutral, das ist nicht auf irgendwas Maß geschneidert, sondern in das Relationale Modell kann ich reinstecken, was ich will, kann eigentlich alles damit tun.

Vorteil, ich kann es überall verwenden, Nachteil, es passt natürlich nicht überall gleich gut, das heißt, es gibt irgendwelche Fälle, da ist halt das Relationale Modell nicht besonders geeignet oder nicht besonders komfortabel.

Und was wir uns jetzt heute anschauen werden, das multidimensionale Modell, das ist eben Maß geschneidert, auf so einen Fall, Datenanalyse ist im Relationalen nicht toll, also machen wir was eigenes, was da genau passt.

Das ist etwas komplizierter, wir haben mehr Konstrukte, die wir zur Modellierung verwenden können und im Ergebnis kommt ein Datenmodell raus, das man eigentlich nur für solche Analysen verwenden kann, aber für die Analysen ist es eben hervorragend und passt genau.

Data Warehouse Systeme, wie sind die aufgebaut? Wir fangen an auf der linken Seite, wir haben eine Reihe von Quellsystemen, aus denen wollen wir Daten irgendwie zusammenfassen.

Also der Gedanke an einem Data Warehouse ist, man nimmt verschiedene operative Systeme, die man schon hat, die sowieso schon Daten sammeln und integriert die von da gemeinsam in ein Data Warehouse, dieses Data Warehouse verwendet man dann für die Auswertung.

Also haben wir auf der linken Seite die Quellen, das sind einmal die normalen operativen Systeme, also zum Beispiel eine Anwendung zur Eingabe von Kunden oder Rechnungen oder so.

Die Daten, die da anfallen, können wir jetzt prinzipiell versuchen zu übernehmen und in ein Data Warehouse einzuspielen.

Das ist der eine Block, der andere Block, den wir da schon sehen, sind sonstige Quellen, es gibt tausend andere Möglichkeiten, wo Daten herkommen könnten, das müssen keine anderen Datenbanken sein und es ist erstaunlich, wie viel in der Praxis da heutzutage noch an einfachen Textdateien hin und her geschoben wird zum Beispiel.

Gut, Datenquellen wollen wir integrieren, dazu haben wir hier diesen Pfeil mit Load beschriftet, wir versuchen die Quelldaten in ein Data Warehouse zu laden, dabei haben wir verschiedene einzelne Schritte, Extract, also wir müssen die Daten erstmal in einer Form, die wir lesen können, aus den einzelnen Systemen rauskriegen.

Integrate, wir müssen sie irgendwie miteinander integrieren, da sind wir in so Bereichen, wo man zum Beispiel über Schlüssel nachdenken muss, vielleicht haben wir mehrere Systeme, die verwalten alle Kundendaten, aber haben unterschiedliche Schlüssel und jetzt wollen wir gleiche Kunden aus verschiedenen Systemen einander zuordnen, das ist der Integrationsschritt.

Da muss man eben gucken, welche Daten gehören überhaupt zusammen, wie kann man die in ein gemeinsames Schema bringen, wo sie alle reinpassen.

Dann haben wir den dritten Teil, Cleans, also säubern, es ist häufig so, dass in operativen Systemen die Qualität der Daten nicht übermäßig gut ist, da kann es passieren, dass ein Haufen Schrott drin steht oder Sachen, die wir in einem Data Warehouse nicht haben wollen,

das heißt an der Stelle versucht man bei der Übernahme die Daten gleich zu bereinigen, um dann eine solide Datenbasis im Data Warehouse zu haben, mit der man auch vernünftige Auswertungen machen kann, wo man auch den Ergebnissen glauben kann.

Und Aggregate als letzter Punkt ist gedanklich nahe an dem, was wir aus SQL an Aggregatsfunktionen kennen, man versucht Daten an der Stelle möglicherweise gleich zusammenzufassen.

Vielleicht interessiert es uns in unserem Data Warehouse überhaupt nicht, wann wir jeden einzelnen Videorekorder verkauft haben, den wir mal verkauft haben, sondern vielleicht wollen wir die Daten an der Stelle schon irgendwie voraggregiert haben.

Wenn wir das geschafft haben, können wir die Daten in ein Data Warehouse übernehmen, sieht auf dem Bild aus wie eine normale Datenbank, ist auch fast eine normale Datenbank, bis auf das unterschiedliche Datenmodell und einige neue Operationen, die wir heute noch sehen werden.

Unten drunter gibt es die Dinger noch mal in klein, sogenannte Data Mards, ein Data Mart können wir uns vorstellen als Teilausschnitt aus einem Data Warehouse, solche Ausschnitte kann man aus verschiedenen Gründen bilden, aus technischen, um die Performance zu erhöhen, aus inhaltlichen oder auch zum Zwecke der Rechtevergabe, dass man sagt, bestimmte Leute sollen nur bestimmte Daten auswerten dürfen.

Sinnvollerweise steckt man dann eben gerade diese Menge an Daten in so einen Data Mart.